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Security Labels in Internet Email 


Abstract 


This document describes a header field, SIO-Label, for use in 
Internet email to convey the sensitivity of the message. This header 
field may carry a textual representation (a display marking) and/or a 
structural representation (a security label) of the sensitivity of 
the message. This document also describes a header field, SIO-Label- 
History, for recording changes in the message’s label. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7444. 


Copyright Notice 


Copyright (c) 2015 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 


A security label, sometimes referred to as a confidentiality label, 
is a structured representation of the sensitivity of a piece of 
information. A security label can be used in conjunction with a 
clearance, a structured representation of what sensitive information 
a person (or other entity) is authorized to access, and a security 
policy to control access to each piece of information. For instance, 
an email message could have an "EXAMPLE CONFIDENTIAL" label that 
requires the sender and the receiver to have a clearance granting 
access to information labeled "EXAMPLE CONFIDENTIAL". X.841 [X.841] 
provides a discussion of security labels, clearances, and security 
policy. 


A display marking is a textual representation of the sensitivity of a 
piece of information. For instance, "EXAMPLE CONFIDENTIAL" is a 
textual representation of the sensitivity. A security policy can be 
used to generate display markings from security labels. Display 
markings are generally expected to be prominently displayed whenever 
the content is displayed. 


Sensitivity-based authorization is used in networks that operate 
under a set of information classification rules, such as in 
government and military agency networks. The standardized formats 
for security labels, clearances, security policy, and associated 
authorization models are generalized and can be used in non- 
government deployments where appropriate. 
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Security labels may also be used for purposes other than 
authorization. In particular, they may be used simply to convey the 
sensitivity of a piece information. The security label could be 
used, for instance, to organize content in a content store. 


This document describes a protocol for conveying the sensitivity of a 


electronic mail message [RFC5322] as a whole. In particular, this 
document describes a header field, SIO-Label, that carries a security 
label, a display marking, and display colors. This document also 


describes a header field, SIO-Label-History, that records changes in 
the message’s security label. 


This protocol is based in part upon "XEP-0258: Security Labels in 
XMPP" [XEP258]. 


1.1. Relationship to Inline Sensitivity Markings 


In environments requiring messages to be marked with an indication of 
their sensitivity, it is common to place a textual representation of 
the sensitivity, a display marking, within the body to the message 
and/or in the Subject header field. For instance, the authors often 
receives messages of the form: 


To: author <author@example.com>; 
From: Some One <someone@example.net>; 
Subject: the subject (UNCLASSIFIED) 


UNCLASSIFIED 
Text of the message. 
UNCLASSIFIED 


Typically, when placed in the body of the message, the marking is 
inserted into the content such that it appears as the first line(s) 
of text in the body of the message. This is known as a FLOT (First 
Line(s) of Text) marking. The marking may or may not be surrounded 
by other text indicating that the marking denotes the sensitivity of 
the message. A FLOT may also be accompanied by a LLOT (Last Line(s) 
of Text) marking. The message above contains a two-line FLOT anda 
two-line LLOT (in both cases, a line providing the marking and an 
empty line between the marking and the original content appear). 


Typically, when placed in the Subject of the message, the marking is 
inserted before or after the contents of the original Subject field; 
it is surrounded by parentheses or the like and/or separated from the 
content by white space. 
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The particular syntax and semantics of inline sensitivity markings 
are generally a local matter. This hinders interoperability within 
an organization wanting to take actions based upon these markings and 
hinders interoperability between cooperating organizations wanting to 
usefully share sensitivity information 


The authors expect that such markings will continue to be widely 
used, especially in the absence of ubiquitous support for a 
standardized header field indicating the sensitivity of the message. 


The authors hope that through the use of a formally specified header 
field, interoperability within organizations and between 
organizations can be improved. 


1.2. Relationship to Preexisting Security Label Header Fields 


A number of non-standard header fields, such as the X-X411 field, are 
used to carry a representation of the sensitivity of the message, 
whether a structured representation or textual representation. 


The authors hope that the use of preexisting (non-standard) header 
fields will be replaced, over time, with the use of the header field 
described in this document. 


1.3. Relationship to Enhanced Security Services for S/MIME 


Enhanced Security Services for S/MIME (ESS) [RFC2634] provides, 
amongst other services, signature services "for content integrity, 
non-repudiation with the proof of origin, and [securely] binding 
attributes (such as a security label) to the original content". 


While it may be possible to utilize the protocol described in this 
document concurrently with ESS, this protocol should generally be 
viewed as an alternative to ESS. 


It is noted that in ESS, the security label applies to MIME [RFC2045] 
content, where in this protocol, the label applies to the message as 
a whole. 


It is also noted that in ESS, security labels are securely bound to 
the MIME content through the use of digital signatures. This 
protocol does not provide message-signing services and hence does not 
provide secure binding the label to the message, content integrity, 
or non-repudiation of the proof of origin. 


This protocol is designed for situations/environments where message 
signing is not necessary to provide sufficient security. 
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Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


The formal syntax specifications in this document use the Augmented 
Backus-Naur Form (ABNF) as described in [RFC5234]. 


The term "base64 encoding" is used to refer to the "Base 64 encoding" 
defined in Section 4 of [RFC4648]. The term "BER encoding" is used 
to refer to encoding per the Basic Encoding Rules (BER) as defined in 
[X.690]. 


Overview 


A Mail User Agent (MUA) originating a message can, if so configured, 
offer the user a menu of sensitivities to choose from and, upon 
selection, insert the display marking, foreground and background 
colors, and security label parameters associated with that selection 
into the SIO-Label header field of the message. 


Mail Submission Agents (MSAs), Mail Transfer Agents (MTAs), and Mail 
Delivery Agents (MDAs) can then, if so configured, use the provided 
sensitivity information (or lack thereof) in determining whether to 
accept, forward, or otherwise act on the message as submitted. These 
agents, hereafter referred to as Service Agents (SAs), can, if so 
configured, modify the sensitivity information of the message, such 
as replacing the security label and/or display marking with 
equivalent representations of the sensitivity of the message. SAs 
that add, modify, or delete the SIO-Label header field SHOULD add an 
SIO-Label-History header. 


Receiving MUAs that implement this extension SHALL, when displaying 
the message, also prominently display the marking, if any, conveyed 
in the SIO-Label header field or, if policy-aware and configured to 
display locally generated markings, a marking generated by the 
conveyed label and the governing policy. It is also desirable to 
display this marking in listings of messages. In the case the 
conveyed marking is displayed, the marking SHOULD be displayed using 
the foreground and background colors conveyed in the header field. 
In the case the marking was generated from a conveyed label and the 
governing policy, the marking SHOULD be displayed using the 
foreground and background colors conveyed by the governing policy. 
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While MUAS are not expected to make authorization decisions based 
upon values of the SIO-Label header field, MUAs can otherwise use the 
provided sensitivity information (or lack thereof) in determining how 
to act on the message. For instance, the MUA may organize messages 
in its store of messages based upon the content of this header field. 


4. The SIO-Label Header Field 


The header field name is "SIO-Label", and its content is a set of 
key/value pairs, each referred to as a parameter. 


Formal header field syntax: 
sio-label = "SIO-Label:" [FWS] sio-label-parm-seq [FWS] CRLF 


sio-label-parm-seq = sio-label-parm 
[ [FWS] ";" [FWS] sio-label-parm-seq ] 


sio-label-parm = parameter 


where the parameter production is defined in [RFC2231], the FWS 
production is defined in [RFC5322], and the CRLF production is 
defined in [RFC5234]. It is noted that the productions defined in 
[RFC2231] rely on the ABNF in [RFC0822], which implicitly allows for 
white space in certain cases. In particular, white space is 
implicitly allowed in the parameter production immediately before and 
after the "=". It is also noted that [RFC2231] allows for quoted- 
string values (for parameter production) of substantial length, for 
string characters outside of US-ASCII, or for other such cases. 
Implementors should consult the referenced specifications for 
details. 


The "marking" parameter is a display string for use by 
implementations that are unable or unwilling to utilize the governing 
security policy to generate display markings. The "marking" 
parameter SHOULD generally be provided in SIO-Label header fields. 

It ought only be absent where an SA relies on other SAs to generate 
the marking. 


The "fgcolor" and "bgcolor" parameters are tokens restricted to color 
production representing the foreground and background colors, 
respectively, for use in colorizing the display marking string. 

Their values are RGB colors in hexadecimal format (e.g., "#ff£0000"), 
or one of the Cascading Style Sheets (CSS) color names (e.g., "red") 
given in named-color type below (the 16 HTML4 colors + "orange") 
[CSS3-Color]. The default foreground color is black. The default 
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background is white. The "fgcolor" 
absent if the "marking" parameter is absent. 
below is defined in [RFC5234]. 


Formal color syntax: 


color = hex-color / named-color 


hex-color = "#" 6HEXDIG ; Hex-encoded RGB 

named-color = 
"aqua" / 
"black" / 
"blue " / 
"fuschia" / 
"gray" vA 
"green" / 
"lime " / 
"maroon" / 
"navy" / 
"olive" / 
"purple" / 
" red" / 
"Silver" / 
"teal" / 
"white" / 
"yellow" / 
"orange" ; named colors 

The "type" 


the string ":x411", the string ":xml", 
parameter value is a quoted string. The 


present if the "label" parameter is present. 


SHALL be present if the "type" parameter is present. 
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and "bgcolor" parameters SHALL be 


The HEXDIG production 


parameter is a quoted string containing the string ":ess", 
or a URI 
the type and encoding of the "label" parameter. 
"type" parameter SHALL be 


[RFC3986] denoting 
The "label" 

The "label" 
When 


parameter 


sensitivity—-based authorization is performed, the absence of the 
"type" and "label" parameters indicates that the message is handled 


under default handling rules (e.g., 


The string ":ess" 


as if no SIO-Label was present). 


indicates that the "label" parameter value is the 


base64 encoding of the BER encoding of an ESS security label 


[RFC2634]. 


Informational 
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ESS Label Example: 


STO-Label: marking="EXAMPLE CONFIDENTIAL"; 
fgcolor=black; bgcolor=red; 
type=":ess"; label="MOQYGASkCAQM=" 


The string ":x411" indicates that the "label" parameter value is the 
base64 encoding of the BER encoding of an X.411 security label 
[X.411]. 
X.411 Label Example: 
STO-Label: marking="EXAMPLE CONFIDENTIAL"; 

fgcolor=black; bgcolor=red; 

type=":x411"; label="MOYGASkCAQM=" 


The string ":xml" indicates that the "label" parameter value is the 


base64 encoding of a security label represented using [XML]. The XML 
prolog SHOULD be absent unless specifically required (such as when 
the character encoding is not UTF-8). The particular flavor of 


security label representation is indicated by the root element name 
and its name space. 


XML Label Example: 


STO-Label: marking="EXAMPLE CONFIDENTIAL"; 
fgcolor=black; bgcolor=red; 
type=":xml"; 
label*0="PFN1LYOxhYmVsTHhtbG5zPSJodHRw0i8vZXhhbxX"; 
label*1="BsZS5jb20vc2VjLWxhYmVsLzAiPjxQb2xpY31JI"; 
label*2="ZGVudGlmaWVyIFVSSTOidXJuOm9pZDoxLjEHiLz"; 
label*3="4802xhc3NpZm1jYXRpb24+MzwvO2xhc3NpaZm1 4"; 
label*4="YXRpb24+PCITZWNMYWI1LbDD4="; 


where the XML label, with new lines and white space added for 
readability, is: 


<SecLabel xmlns="http://example.com/sec-label/0"> 
<PolicyIdentifier URI="urn:oid:1.1"/> 
<Classification>3</Classification> 
</SecLabel> 


The "sess" and ":x411" formats SHOULD be used to represent ESS or 
X.411 security labels, respectively, instead of any direct XML 


representation of these formats. 


The header field SHALL minimally contain a "marking" parameter or 
contain both the "type" and "label" parameters. 
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This header field may be extended to include additional parameters by 
future document formally updating (or replacing) this document. 
Implementations SHOULD ignore additional parameters they do not 
recognize. This recommendation is not a mandate so as to allow 
agents to process a message with an SIO-Label header field with 
unrecognized parameters differently than a message with an SIO-Label 
header field without the unrecognized parameters. 


Each message SHALL contain zero or one SIO-Label header field. 
Extended Example: 


SIO-Label: marking*=us-ascii’ en’ EXAMPLES20CONFIDENTIAL; 
fgcolor = black ; bgcolor = red ; 
type=":ess"; label*0="MOYG"; 
label*1="ASkCAQM=" 


The Extended Example is equivalent to the ESS Label Example above. 
5. The SIO-Label-History Header Field 


Any service agent MAY record label changes in an SIO-Label-History 
header. This header field is intended to provide trace information 
(and only trace information). For instance, it can be used to record 
the label change when an SIO-Label header is added, modified, or 
deleted by a service agent. This field can be used in other 
situations as well. For instance, a gateway that translates X.400 
messages to RFC 5322 mail can use this header field to record 
labeling changes made while translating a message. 


The SIO-Label-History header field is considered to be a trace field 
as defined in Section 3.6.7 of [RFC5322]. 


The formal syntax of the SIO-Label-History header is the same as the 
SIO-Label, but with the following parameters: 


o change - one of "add", "replace", "delete". 


o changed-by - contains a string identifying the agent, commonly the 
agent’s fully qualified domain name. 


o changed-at - contains a date-time production, as specified in 
[RFC5322], representing the date and time the header was 
rewritten. 

o changed-comment - contains a string containing a comment. 
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o marking, fgcolor, bgcolor, type, label - records the message’s 
label information prior to adding, modifying, or deleting SIO- 
Label, using the same parameter syntax used for SIO-Label. These 
parameters are absent when the change action is "add". 


o new-marking, new-fgcolor, new-bgcolor, new-type, new-label - 
records the message’s label information after adding, modifying, 
or deleting SIO-Label, using the same parameter syntax used for 
corresponding SIO-Label parameters. These parameters are absent 
when the change type is "delete". 


The header field SHALL minimally contain the "change", "changed-by", 
and "changed-at" parameters. 


This header field can be extended to include additional parameters by 
future documents formally updating (or replacing) this document. 


Each message can contain zero or more SIO-Label-History header 
fields. All SIO-Label-History header fields should immediately 
follow the SIO-Label header field, if any, and be grouped together. 
Additional SIO-Label-History header fields should be added 
immediately preceding any existing SIO-Label-History header fields. 
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SIO Label History Add, Modify, Delete Example: 


SIO-Label-History: marking="EXAMPLE CONFIDENTIAL"; 
fgcolor=black; bgcolor=red; 
type=":xml"; 
label*0="PFN1LYOxhYmVsTHhtbG5zPSJodHRw0i8vZXhhbxX"; 
label*1="BsZS5jb20vc2VjLWxhYmVsLzAiPjxQb2xpY31JI"; 
label*2="ZGVudGlmaWVyIFVSSTOidXJuOm9pZDoxLjEHiLz"; 
label*3="4802xhc3NpZm1jYXRpb24+MzwvO2xhc3Np2Zm1 45"; 
label*4="YXRpb24+PCITZWNMYWI1LbD4="; 
change=delete; 
changed-by="delete.example.com"; 
changed-at="18 Feb 2013 9:24 PDT"; 
changed-comment="delete" 

SIO-Label-History: marking="EXAMPLE CONFIDENTIAL"; 
fgcolor=black; bgcolor=red; 
type=":ess"; label="MQYGASkCAQM="; 
new-marking="EXAMPLE CONFIDENTIAL"; 
new-fgcolor=black; new-bgcolor=red; 
new-type=":xml"; 
new-label*0="PFNLYOxhYmVsTIHhtbG5zPSJodHRw0i8vZxXhhbx"; 
new-label*1="BsZS5jb20vc2VjLWxhYmVsLzAiPjxQb2xpY31J"; 
new-label*2="ZGVudGlmaWVyIFVSSTO0idxXJuOm9pZDoxLjEBiLz"; 
new-label*3="4802xhc3NpZm1 JYXRpb24+MzwvO2xhc3NpZm14"; 
new-label*4="YXRpb24+PC9ITZWNMYWJI1LbD4="; 
change=replace; 
changed-by="modify.example.net"; 
changed-at="18 Feb 2013 8:24 PDT"; 
changed-comment="replaced with XML variant" 

SIO-Label-History: new-marking="EXAMPLE CONFIDENTIAL"; 
new-fgcolor=black; new-bgcolor=red; 
new-type=":ess"; new-lLabel="MOYGASkKCAQM="; 
change=add; 
changed-by="add.example.net"; 
changed-at="18 Feb 2013 7:24 PDT"; 
changed-comment="added label" 
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6. 


IANA Considerations 


The SIO-Label and SIO-Label-History header fields have been 
registered in the "Provisional Message Header Field Registry" in 
accordance with [RFC3864]. 


Header field name: SIO-Label 

Applicable protocol: mail [RFC5322] 

Status: provisional 

Author/change controller: Kurt Zeilenga (kurt.zeilenga@isode.com) 
Specification document(s): RFC 7444 


Header field name: SIO-Label-History 

Applicable protocol: mail [RFC5322] 

Status: provisional 

Author/change controller: Kurt Zeilenga (kurt.zeilenga@isode.com) 
Specification document(s): RFC 7444 


Security Considerations 


Sensitive information should be appropriately protected (whether 
labeled or not). For email messages, it is generally appropriate for 
the sending entity to authenticate the receiving entity and to 
establish transport-level security, including protective services for 
both data integrity and data confidentiality. When a receiving 
entity makes authorization decisions based upon assertions of the 
sending entity, including assertions of identity, it is generally 
appropriate for the receiving entity to authenticate the sending 
entity. 


This document provides a facility for expressing the sensitivity of 
an email message. The mere expression of actual sensitivity 
generally does not elevate the sensitivity of the message; however, 
expressions of sensitivities can themselves be regarded as sensitive 
information. For instance, a marking of "BLACK PROJECT RESTRICTED" 
could disclose the existence of a sensitivity project. 


The SIO-Label header field expresses the sensitivity of the whole 
message, including the header and body. This document does not 
provide a means to express the sensitivity of portions of an email 
message, such as the possibly different sensitivities of various MIME 
parts that the message may be composed of. The approach used in this 
document favors simplicity and ease of use (i.e., a single expression 
of sensitivity) over the complexity and difficulty of marking and 
labeling portions of a message. 
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The expressed sensitivity can be used in determining how to handle a 
message. For instance, the value of the SIO-Label header field (or 
lack thereof) can be used to determine if it is appropriate to be 
forwarded to a particular entity and, if so, what minimum security 
services ought to be used in the forwarding exchange. The mechanism 
for determining how to handle a message-based expressed sensitivity 
is beyond the scope of this document. 


The actual content may have more or less sensitivity than indicated 
by the security label. Agents should avoid lowering security 
requirements for message exchange with a particular entity based upon 
conveyed sensitivity. 


This protocol does not itself provide message-signing services, such 
as used in providing message integrity protection, non-repudiation, 
and binding of attributes (such as the security label to the 


message). While it possible that this protocol could be used with a 
general message-signing service, this document does not detail such 
use. 


While security label and display marking parameters are expected to 
express the same sensitivity, nothing in this specification ensures 
that the security label and display marking values express the same 
sensitivity. For instance, an MUA could submit a message that 
contains a security label that expresses one sensitivity anda 
display marking with a different sensitivity, and by doing so, 
possibly cause an SA to inappropriately handle the message. It is 
generally appropriate for each SA using the SIO-Label values to 
determine if the security label and display marking values express 
the same sensitivity and, if not, take appropriate action (such as 
rejecting the message). 


This document also provides a facility for expressing changes to the 
label of a message. This is intended to be used for trace purposes 
only. It is noted that the SIO-Label-History header field can 
include sensitive information and, as such, can be removed from the 
message when its inclusion would result in disclosure of 
inappropriate information. 
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